Windows Azure : Programming Access Control Service (part 8)

2.1. Configuring ACS to Accept SAML Tokens

In the previous example, you created a service namespace, token policy, and scope in ACS for processing SWT tokens generated by the web service consumer client. This example uses the same service namespace and token policy and only configures ACS to process the SAML token issued by the custom STS. If you don't have the token policy ID from the previous example, you can get all the token policies from the service namespace by executing the following command:

Acm.exe getall tokenpolicy

Figure 9 shows the output of the getall token policy command.

Figure 9. Get all token policy

Figure 9 shows that there are two token policies in the service namespace. Your service namespace may have only one token policy. Note down the token policy ID of the token policy named acsexample. The value of your ID will be different than the one in this example.

Next, you have to register the SAML token issuer with ACS. If you've installed the Identity Developer's Kit, run Setup.cmd for the Introduction to Access Control Service lab from the following directory: C:\IdentityTrainingKit\Labs\IntroAccessControlService\Source\Setup.

On successful installation, open the LocalSTS.sln solution. In WindowsSecurityTokenService.cs, replace "Pilot" with "domainadmin" in the GetOutputClaimsIdentity function, as shown in Listing 10.

Example 10. GetOuputClaimsIdentity

protected override IClaimsIdentity GetOutputClaimsIdentity
(IClaimsPrincipal principal, RequestSecurityToken request, Scope scope)
        {
            IClaimsIdentity callerIdentity = (IClaimsIdentity)principal.Identity;

            IClaimsIdentity outputIdentity = new ClaimsIdentity();

            Claim nameClaim =
new Claim(System.IdentityModel.Claims.ClaimTypes.Name, callerIdentity.Name);
            Claim groupClaim =
new Claim("http://schemas.xmlsoap.org/claims/Group", "domainadmin");

            outputIdentity.Claims.Add(nameClaim);
            outputIdentity.Claims.Add(groupClaim);

            return outputIdentity;
}

					  

Compile the LocalSTS project. Then, Run LocalSTS.exe from C:\IdentityTrainingKit\Labs\IntroAccessControlService\Source\Ex02-UsingACSWithSAMLTokens\Assets (see Figure 10). LocalSTS.exe is a SAML token issuer that simulates the token-generation function of ADFS v2.0.

Figure 10. Running LocalSTS.exe

The X.509 certificate path and the STS URL are configured in LocalSTS.exe.config, as shown in Listing 11.

Example 11. LocalSTS.exe.config

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <appSettings>
    <add key="signingCertName" value="CN=localhost"/>
    <add key="stsBaseAddress" value="localhost/localsts"/>
    <add key="stsPath" value="Trust/13/UserName"/>
  </appSettings>
</configuration>

The Introduction to Access Control Service lab in the Identity Developer Training Kit also consists of a client utility named FedMetadataClient.exe located in the C:\IdentityTrainingKit\Labs\IntroAccessControlService\Source\Ex02-UsingACSWithSAMLTokens\Assets directory for creating LocalSTS as a trusted issuer in ACS.

Configure the FedMetadataClient.exe tool in FedMetadataClient.exe.config to point to your service namespace, management key, and the relying party URL, as shown in Listing 12.

Example 12. FedMetadataClient.exe.config

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <appSettings>
    <add key="stsBaseAddress" value="localhost/localsts"/>
    <add key="stspath" value="Trust/13/UserName"/>
    <add key="serviceNamespace" value="{Enter your service namespace}"/>
    <add key="acsHostName" value="accesscontrol.windows.net"/>
    <add key="applies_to" value="{Enter URL of the Relying Party or web service"/>
    <add key="mgmtKey" value="{Enter management key of your service namespace"/>
  </appSettings>
</configuration>

					  

Run the FedMetaDataClient tool from the command line. The FedMetaDataClient tool reads the metadata of the LocalSTS and calls the ACS management service API to register a new token issuer.

Run the "Acm.exe getall issuer" command to retrieve all the registered issuers in the service namespace, as shown in Figure 11.

Figure 11. Getting all issuers

You should see the newly created issuer with the name format {service namespace}SAML. Copy and save the ID of the issuer, which is of the format id:iss_XXX. You use this issuer ID to create a new rule later.

Get the scope ID by executing the "acm.exe getall scope" command. This lists all the scopes in your service namespace, as shown in Figure 12.

Figure 12. Getting all scopes

This example uses the same scope (acsexample) you used in the previous example. Copy and save the scope ID of the acsexample scope. The scope ID is of the format id:scp_XXX.

When you have the issuer ID and the scope ID, you can create the rule for mapping input claims from the SAML token to the output claims in the SWT token issued by ACS. Because you're using the same web service (ACSMachineInfo) from the previous example, the output claims remain similar to the previous example, but the input claims change to reflect the claims generated by the LocalSTS. In this example, Table 3 lists the mapping between input claims and output claims.

The SAML token should include an input claim type http://schemas.xmlsoap.org/claims/Group with a value of domainadmin. This input claim is mapped to the output claim type of action with a value of encodestring. This means that all the users in the domainadmin group can call the EncodeString() function in the ACSMachineInfo web service. The command to create a new rule is as follows:

.\acm.exe create rule
-scopeid:scp_8a326d8b34f7ce67fc3c8f2cfc0cabb1df7c35a9
 -inclaimissuerid:iss_46dea15e5e89cfe6dd44eb1c1c79449133a11744
-inclaimtype:http://schemas.xmlsoap.org/claims/Group
-inclaimvalue:domainadmin
-outclaimtype:action
-outclaimvalue:encodestring
-name:domainadminencodestring

When executing the command, you need the scope ID and issuer ID you retrieved from ACS earlier. Figure 13 shows the output of the create rule command.

Figure 13. Creating a rule